Trip termination determination for on-demand transport

ABSTRACT

A transport arrangement service can determine a point of trip termination for a trip. The point of trip termination can be validated based on information collected from a computing device of a driver and a trip termination input from the driver.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.15/182,217, filed on Jun. 14, 2016; which is hereby incorporated byreference in its entirety.

BACKGROUND

On-demand transportation services are technology-based services whicharrange trips for a variety of purposes (e.g., user transport, packagedelivery) using available transport resources (e.g., vehicles of users).Such services can be technologically-centric with respect to, forexample, the manner in which the services use computing devices of usersfor tasks such as pairing vehicles (or drivers) to transportationrequests, enabling limited or controlled communications between partiesor through the network service, remotely monitoring vehicles andresources in use, calculating fares and a variety of other tasks. On agroup level, such services can aggregate information (e.g., position,state) from numerous users in order to determine information such astraffic congestion, supply/demand and various other facets of theservice.

A service arrangement system can arrange an on-demand service, such as atransport service, to be performed by a service provider (e.g., driver)for a requesting user through the use of a mobile computing device.Typically, when the vehicles arrives at a destination (e.g., selected bythe rider), the driver provides input signifying the trip has ended. Theservice arrangement system can use information about the route todetermine the price for the transport service, and such calculationtypically involves determining the location where the driver identifiesas being the point of trip termination.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system to programmatically a point of tripdetermination in connection with a transport service.

FIG. 2A illustrates an example method for programmatically determining apoint of trip termination in connection with a trip arranged through atransport service.

FIG. 2B illustrates another example method for programmaticallydetermining a point of trip termination in connection with a triparranged through a transport service.

FIG. 3 illustrates another example method for programmaticallydetermining a point of trip termination in connection with a triparranged through a transport service.

FIG. 4 is a block diagram that illustrates a mobile computing deviceupon which embodiments described herein may be implemented.

FIG. 5 is a block diagram that illustrates a computer system upon whichexamples described herein may be implemented.

DETAILED DESCRIPTION

Examples includes a transport arrangement service that determines apoint of termination for a trip based at least in part on passiveinformation collected from a computing device of a driver. The passiveinformation may include computer-generated data that is notuser-initiated or generated through user intent or input. Multiple typesof passive information may be collected and utilized in determining thepoint of termination for a trip. Examples of passive informationcollected from a computing device include location information (e.g.,such as provided from a GPS component of a computing device), motionsensor information (e.g., such as provided by an accelerometer orgyroscope component of a computing device), environmental information(temperature, barometer, etc.) within the passenger cabin, audio input(such as recorded by the microphone of a computing device) or othertypes of sensor information (e.g., vehicle telemetry information such asprovided through through an on-board computer of vehicle to collectOn-Board Diagnostic data).

In examples described herein, the system can be implemented using amobile computing device of a driver. In some variations, the driver'smobile computing device can execute a service application (e.g., “app”which the user can download), and the service application can implementoperations that include (i) communicating over a network with atransport arrangement service, (ii) communicating a state of the driver(e.g., that runs on the driver device (e.g., a driver application).

As used herein, a client device, a driver device, a computing device,and/or a mobile computing device refer to devices corresponding todesktop computers, cellular devices or smartphones, personal digitalassistants (PDAs), laptop computers, tablet devices, etc., that canprovide network connectivity and processing resources for communicatingwith a remote system(s) over one or more networks, such as a servicearrangement system. In one example, a driver device can also correspondto custom hardware of a vehicle, such as an in-vehicle computing device,that has network connectivity and location-determination capabilities.

Still further, examples described herein relate to a variety oflocation-based (and/or on-demand) services, such as a transport service,a food truck service, a delivery service, an entertainment service, etc.to be arranged between users and service providers. In other examples, aservice arrangement system can be implemented by any entity thatprovides goods or services for purchase through the use of computingdevices and network(s). For purpose of simplicity, in examples describedherein, the service arrangement system can correspond to a transportarrangement system that arranges transport services to be provided forriders by drivers of vehicles.

One or more examples described herein provide that methods, techniques,and actions performed by a computing device are performedprogrammatically, or as a computer-implemented method. Programmatically,as used herein, means through the use of code or computer-executableinstructions. These instructions can be stored in one or more memoryresources of the computing device. A programmatically performed step mayor may not be automatic.

One or more examples described herein can be implemented usingprogrammatic modules, engines, or components. A programmatic module,engine, or component can include a program, a sub-routine, a portion ofa program, or a software component or a hardware component capable ofperforming one or more stated tasks or functions. As used herein, amodule or component can exist on a hardware component independently ofother modules or components. Alternatively, a module or component can bea shared element or process of other modules, programs or machines.

Some examples described herein can generally require the use ofcomputing devices, including processing and memory resources. Forexample, one or more examples described herein may be implemented, inwhole or in part, on computing devices such as servers, desktopcomputers, cellular or smartphones, personal digital assistants (e.g.,PDAs), laptop computers, printers, digital picture frames, networkequipment (e.g., routers) and tablet devices. Memory, processing, andnetwork resources may all be used in connection with the establishment,use, or performance of any example described herein (including with theperformance of any method or with the implementation of any system).

Furthermore, one or more examples described herein may be implementedthrough the use of instructions that are executable by one or moreprocessors. These instructions may be carried on a computer-readablemedium. Machines shown or described with figures below provide examplesof processing resources and computer-readable mediums on whichinstructions for implementing examples described herein can be carriedand/or executed. In particular, the numerous machines shown withexamples described herein include processor(s) and various forms ofmemory for holding data and instructions. Examples of computer-readablemediums include permanent memory storage devices, such as hard drives onpersonal computers or servers. Other examples of computer storagemediums include portable storage units, such as CD or DVD units, flashmemory (such as carried on smartphones, multifunctional devices ortablets), and magnetic memory. Computers, terminals, network enableddevices (e.g., mobile devices, such as cell phones) are all examples ofmachines and devices that utilize processors, memory, and instructionsstored on computer-readable mediums.

Additionally, examples may be implemented in the form ofcomputer-programs, or a computer usable carrier medium capable ofcarrying such a program.

SYSTEM DESCRIPTION

FIG. 1 illustrates a transport arrangement system to programmaticallydetermine a point of trip termination, according to one or moreexamples. According to some examples, a transport arrangement system 100as shown with an example of FIG. 1 can validate and/or correct a pointof trip termination as identified by a driver on a trip. The point oftrip termination can correspond to a location, as defined by, forexample, longitude and latitude where a trip is deemed to end. In someexamples, the service 100 determines the point of trip determinationusing driver input and passive information collected from the vehicle.In variations such as described with an example of FIG. 2B, the service100 can independently determine a point of trip termination withoutinput from driver or rider.

In an example of FIG. 1, functionality for determining the point of triptermination is performed using computing resources (e.g., one or moreservers) of the service 100. In variations, the functionality fordetermining the point of trip termination is distributed, using, forexample, logical components or processes that are executed on, forexample, computing devices of the driver or rider.

With further reference to FIG. 1, the transport arrangement service 100includes a driver interface 102 a rider interface 104, a transportarrangement component 116, a trip monitor 120 and a trip terminationdeterminator 130. The driver interface 102 includes processes forestablishing separate and independent network connections with computingdevices of drivers (“driver devices 20”). The driver devices 20 maycommunicate, via network 12, driver identification, and informationabout the service state of the driver. For example, the operationalstate of a driver can include state information that indicates whetherthe driver is available (or not available) to provide a transportservice that is facilitated by the transport arrangement service 100.

Likewise, the rider interface 104 includes processes for establishingseparate and independent network connections with competing devices ofriders.

The rider devices 30 may communicate, via the network 12, rideridentification and information about the service state of the rider. Forexample, the riders may include those users of the transport arrangementservice 100 who, in a given time period, are receiving transport, haverequested but have not yet received transport, and/or may or otherwiseare capable of requesting transport.

According to some examples, the driver devices 20 can correspond tomobile computing devices that are operated or otherwise associated withcorresponding drivers. In some examples, the driver devices correspondto multifunctional wireless devices used for Web-enabled activities,cellular and/or other wireless communications, including messaging(e.g., SMS, email, instant messaging) and telephony. By way of example,the driver device can correspond to a smartphone or feature phone, or toa cellular-enabled tablet device. In some variations, the driver device20 can be integrated with a corresponding vehicle that is assigned orotherwise associated with the driver for purpose of providing transportservices. Similarly, the rider devices 30 can correspond to mobilecomputing devices that are operated by riders. Examples of rider devices30 may also include multifunctional wireless devices used forWeb-enabled activities, cellular and/or other wireless communications,including messaging (e.g., SMS, email, instant messaging) and telephony.In some examples, the driver device 20 and/or the rider device 30 cancorrespond to devices of a type that users typically carry on theirpersons in everyday activities, such as a cellular telephony device,tablet, or wearable electronic device.

Each of the driver and rider devices 20, 30 can operate a correspondingservice application 190, 192 to enable the respective driver or rider tocommunicate with the service 100 via a network 12, and to utilize theservice 100 in connection with providing (by driver) or receiving (byrider) transport services. Each of the service applications 190, 192 mayprovide the respective driver and rider device 20, 30 of the particularuser class (driver or rider) with functionality to enable or facilitatethe user in utilizing the service 100. For the driver, suchfunctionality can include (i) automatically interfacing with componentsof the driver device 20, including hardware and software resources ofthe driver device 20, in order to obtain and transmit driver device data103 (e.g., driver identification, driver location and driver servicestate) to the service 100; (ii) receiving transport requests orassignments based on criteria that includes the location of the driver'svehicle and/or the driver's vehicle type; (iii) receiving routinginformation for enabling or facilitating the driver in fulfilling atransport request or assignment; and/or (iv) communicating status of thedriver or trip on which the driver is assigned.

For the rider devices 30, the service application 192 can implementfunctionality to (i) automatically interface with components of therider device 30, including hardware and software resources of the riderdevice 30, in order to obtain and transmit rider device data 109; (ii)provide user interfaces for enabling the rider to make transport requestand to specify information such as pick-up and/or drop-off locations;(iii) provide riders with status or feedback about transport requestsand/or trips which the rider is on or recently received; and/or (iv)enable or provide customer services and functionality, such as enablingcustomers to link funds, provide rating or feedback for servicesreceived, and/or generate customer complaints. When devices 20, 30 ofrespective drivers and riders execute the corresponding serviceapplications 190, 192, the devices 20, 30 may operate as extensions orinformation sources of the service 100.

In an example, drivers may be tracked by the service 100 via therespective driver interface 102. The service 100 may maintain an activedriver data store 118 based at least in part on the driver data 103communicated from the driver device 20. The driver data 103 can identifythe driver, identify a current (or expected) location of the particulardriver, and/or identify a service state of the driver. By way ofexample, the service state of the driver can correspond to available ornot available. In other examples, the service state of the driver cancorrespond to available, en route to pick-up, or on trip.

In an example of FIG. 1, a given rider operates a corresponding riderdevice 30 in order to signal a ride request 106 via the serviceapplication 192 running on the rider device 30. The ride request 106 canspecify the rider's identifier and a pick-up location for the rider'stransport request. Additionally, in some examples, the rider caninteract with the rider device 30 via the service application 192 inorder to specify the rider destination input 107 for the ride request.For example, the rider may specify an address or interact with a mapinterface in order to drop a pin corresponding to the drop off locationdesired by the rider. The rider interface 104 can receive the riderequest 106 (including the rider destination input 107), and theninitiate a transport request signal 121 to the transport arrangementcomponent 116. Among other functions, the transport arrangementcomponent 116 can perform operations that include identifying andpairing a driver with a given rider request 106. In connection with agiven rider request 106, the transport arrangement component 116 mayalso receive a destination input 117, corresponding to or based off ofthe rider destination input 107 (e.g., rider-specified drop-offlocation).

The transport arrangement component 116 may select a driver from theactive driver data store 118, and signal driver selection 119 and tripinformation 123 for the transport request 106. The driver selection 119may identify the driver. The driver interface 102 may signal the tripinformation 123 to the selected driver, where the trip informationincludes a rider identifier and a pick-up location of the trip.Additionally, the trip information 123 may include the drop-off locationas specified by the rider destination input 107 the transport request106. The service application 190 of the selected driver can disclose thetrip information 123 to the driver in accordance with a protocol. Forexample, the destination specified by the rider may be disclosed afterthe trip has been initiated.

The trip may start when the rider enters the vehicle. In some examples,the trip start may be signaled by the driver providing a trip startinput 131. At the end of the trip, the driver may also provide a triptermination input 133. Each of the trip start 131 and trip terminationinputs 133 can be associated with a location, determined from, forexample, the service application 190 interacting with the GPS componentof the driver device 20. While the trip is in progress, the driverinterface 102 receives trip data 105 from the driver device 20. The tripdata 105 may include sensor data from the driver device 20. In oneimplementation, the trip data 105 can include position information,determined from the service application 190 interfacing with with a GPSdevice of the driver device 20. In variations, the trip data 105 caninclude acceleration data from the service application 190 interfacingwith an accelerometer and/or gyroscope of the driver device 20. Stillfurther, the trip data 105 can include sensor data from other sensors ofthe driver device 20, such as a magnetometer, camera, or microphone ofthe driver device 20. In other variations, the trip data 105 includesenvironmental sensor data, from sensor devices such as thermometers orbarometers. Still further, the trip data 105 can include data which thedriver device 20 acquires from an onboard computer of the vehicle (e.g.,telemetry data, OBD data), or through interaction with integrated orembedded sensor devices of the vehicle.

From the driver device 20, the trip monitor 120 may receive or collectthe trip start input 131, the driver trip data 105 for the trip inprogress, and the trip termination input 133. In variations, the tripmonitor 120 may also receive rider trip data 125 from the rider device30, via the service application 192 communicating with the riderinterface 104 of the service 100.

The trip data store 124 represents memory which holds the trip data 105,125, as well as trip start input 131 and trip termination input 133 fordetermining the beginning and end of the trip. The trip data store 124may also include rider-inputs such as the rider destination input 107and/or the pick-up location.

The trip termination determinator 130 may monitor the trip data store124 for a condition that signals the end of the trip. According to someexamples, a trip determination condition 135 can correspond or correlateto the trip termination input 133 provided by the driver, via theservice application 190. As an addition or alternative, the rider inputcan be used for the trip determination condition 135. Still further, thetrip determination condition 135 can be determined from comparing tripdata 105, 125 obtained from the respective driver and rider devices 20,30. For example, the trip data 105, 125 obtained from the respectivedriver and rider devices 20, 30 can correspond to position informationfrom each device, and the trip data store 124 may generate the tripdetermination condition 135 when the position information of the driverand rider is sufficiently disparate to indicate that the rider anddriver or not in the same vehicle.

In some variations, the trip data 105 can include sensor data from atleast one of the driver or rider computing device 20, 30, signifying thetermination of the trip. In one implementation, a microphone of thedriver device 20 may listen for and detect the sound of a car doorclosing. When the sound is heard, the driver device 20 may infer thetrip is terminated, as the rider has likely left the vehicle. In such anexample, the trip termination condition 135 can correspond to an audioinput signal that matches to the sound of the vehicle's door openingand/or closing.

In other variations, the trip data 105 may include sensor data (e.g.,from a barometer of the driver computing device 20) which detects fromsensors which can detect environmental conditions such as temperature orbarometric changes within the vehicle. When the car door opens andcloses (presumably to allow for the rider to leave), the change inenvironmental conditions (e.g., barometric reading)can signify thetermination of the trip. In such an example, the trip terminationcondition 135 can correspond to an environmental sensor reading (e.g.,barometric value, temperature) which is indicative of the vehicle dooropening and closing.

Once the trip termination determinator 130 determines that triptermination condition 135 is present, the trip termination determinator130 can validate a point of the trip termination. When trip terminationcondition 135 is determined from, for example, driver termination input133, the location associated with the driver termination input 133 canbe used as a driver-specified point of termination. The trip terminationdeterminator 130 can process the trip data 133 to validate (orinvalidate) the point of termination. In an example of FIG. 1, the triptermination determinator 130 can validate the point of trip termination143 and store the point of trip termination with the trip data store124. In some examples, other components of the service 100, such as faredetermination logic 144, can interface with the trip data store 124 inorder to determine the fare 147 for the trip based on the validatedpoint of trip termination 143. The fare determination component 144 canoutput the corresponding fare 147 (or value for fare) to the serviceapplications 190, 192 of the corresponding driver and rider devices 20,30, via the respective driver and rider interfaces 102, 104.

In one example, the trip data 105 is analyzed to detect whether thedriver's vehicle came to a stop at or near the driver-specified point oftermination (or when the driver termination input 133 is received). Inone implementation, if the driver-specified point of termination isdeemed equivalent to the vehicle's stopping location, then thedriver-specified point of termination can be validated as the tripdetermination point 143.

According to various examples, the trip termination determinator 130 maybe implemented with rules or other logic for validating, correctingand/or refining the driver-specified point of termination as thevalidated point of termination 143. According to some examples, the triptermination determinator 130 responds to trip termination condition 135by determining whether the driver's vehicle stopped within a setduration of time from the location that correlates to the drivertermination input 133. In one implementation, if the vehicle isdetermined to have stopped in that set duration of time, then thelocation where the vehicle was determined to have stopped can be assumedas the point of termination 143 if that location is different from thelocation correlating to the driver termination input 133.

In variations, the trip termination determinator 130 can receive therider destination input 107. The point of trip termination 143 cancorrespond to the location where the vehicle stopped closest to therider destination input 107. In other examples, the trip terminationdeterminator 130 can determine the point of trip termination 143 tocorrespond to the location where the vehicle stopped immediately after alocation of the rider destination input 107.

In some examples, a model determination component 140 may interface withthe trip data store 124 to determine training data corresponding tocorrelations between (i) a location corresponding to where the driverindicated the trip to have terminated, or alternatively, where sensorinformation from the driver or rider computing device 20, 30 indicatesthat the trip has terminated; (ii) the destination, based on the riderdestination input; and/or (iii) the point of termination, as determinedprogrammatically from, for example, validating, correcting or refiningthe termination point indicated by the driver termination input 133. Anoutput of the model determination component 140 can be a model 149 whichcan be implemented by the trip termination determinator 130 to determinea model candidate point of termination 143 based on trip data 105,driver termination input 133 and/or rider destination input 107. Indetermining or training the model 149, the model determination component140 may also receive input from the rider and/or driver regarding themodel candidate point of termination 143 so that the model is supervisedwhen trained. The model 149 can be based on data from a specific driver,a group of drivers which share a particular set of characteristics(drivers in a particular geographic region) or trips which share aparticular set of characteristics.

In some variations, the model determination component 140 generates themodel 149 to identify the point of trip termination using sensor inputdetected from the driver computing device 20, signifying the departureof the rider (e.g., door opens and closers, barometric reading withinvehicle changes) and trip data 105. Thus, in such variations, no inputmay be needed from the driver when determining when the trip ends.

Methodology

FIGS. 2A, 2B and 3 illustrate example methods for programmaticallydetermining points of trip termination in connection with trips arrangedthrough a transport service. Methods such as described by examples ofFIGS. 2A, 2B and 3 can be implemented using, for example, componentsdescribed with an example of FIG. 1. Accordingly, references made toelements of FIG. 1 are for purposes of illustrating a suitable elementor component for performing a step or sub-step being described. Forpurpose of simplicity, the example methods of FIGS. 2A, 2B and 3 aredescribed as being performed by the service 100, operating inconjunction with data received from a driver device.

With reference to FIG. 2A, the service 100 operates to collect passiveinformation from the driver device 20 (210). The passive informationincludes data generated from the driver device 20 (212) that is not userinitiated or generated through user intent or input. Rather, the passiveinformation can include clock signals, GPS position information, andother sensor data generated from the driver device 20 (e.g., data fromreading accelerometer or gyroscope, microphone input, camera input,etc.) in connection with a trip. In an example of FIG. 1, the trip data105 can include passive information collected from the driver device 20.In some variations, passive information may also include data generatedfrom the rider device 30 (214). For example, the passive information mayinclude some or all of the passive information collected from the driverdevice 20.

According to some examples, the service 100 may receive input from thedriver signaling the trip has terminated (220). In an example of FIG. 1,the driver may provide trip termination input 133, and the triptermination input 133 can be correlated to a particular location (e.g.,using the GPS device of the driver device 20).

The service 100 may operate to determine the point of trip terminationbased on the driver input and the passive information collected from thedriver device 20 (230). For example, the passive information may includetrip data 105 from the driver device 20, including GPS data,accelerometer and/or gyroscope data and/or microphone data. Some or allof the same information may be collected as part of the trip data 125for the rider device 30. The trip data 105, 125, along with the drivertermination input 133 can be used to determine (or approximate) thepoint of trip termination for the particular trip.

According to some examples, the trip data 105, 125 is used to validatethe point of termination, which may initially correspond to the locationcorresponding to where the trip termination input 133 was signaled(232). In one implementation, the location of the trip termination input133 is identified as the point of trip termination if that location isapproximately the location of the where the vehicle came to a stop, asdetermined from the trip data 105.

In some variations, the trip data 105, 125 is used to correct the pointof termination, as initially determined by the location corresponding tothe termination input 133 (234). In one scenario, the driver may signalthe trip termination input 133 too soon, when, for example, the vehicleis in motion and/or a distance from the destination as identified fromthe rider destination input 107. When the trip termination input issignaled too soon, the service 100 can extend the trip to, for example,the first location after the trip termination input 133 when the vehiclestops, or the location where the vehicle stops which is closest to therider destination input 107.

In another scenario, the driver may signal the trip termination input133 too late (e.g., the driver forgets to stop the trip). For example,the vehicle may be in motion when the trip termination input 133 isreceived from the driver. The trip data 105 may be analyzed to determinewhen the vehicle was most recently stopped relative to the location ofthe vehicle corresponding to the trip termination input 133. If thevehicle was stopped before the location corresponding to the triptermination input 131, the service 100 may shorten the trip based on anassumption that the trip ended when the vehicle stopped precedingreceipt of the trip termination input 131 from the driver.

The trip termination input 131 may also be deemed too late if the triptermination input 131 is received after the vehicle passes the drop-offlocation, as identified by the rider destination input 107. As describedwith other examples, the trip data 105 may be analyzed to determine theclosest location closest where the vehicle is determined to have stoppedas compared to the drop-off location specified by the rider destinationinput 107.

According to another variation, a vehicle stopping location, asdetermined from the trip data 105, may be used as the point oftermination in place of the location indicated by the driver'stermination input 133 (236). For example, the location corresponding thetrip termination input 133 may be compared to the closest location wherethe trip data 105 indicates the vehicle may have stopped to end thetrip. If the distance exceeds a threshold, the location where thevehicle is indicated to have stopped may replace the locationcorresponding to the trip termination input 133 as the point oftermination for the trip.

In some examples, the driver device 20 may be configured to continuouslyping for the rider device (once the ride has initiated) such that whenthe rider exits the vehicle, the loss of proximity by the rider deviceis instantly detected. As an addition or alternative, the driver device20 can utilize a microphone to detect when the vehicle's car door opensand closes. Still further, the driver computing device 20 may includesensor devices for detecting changes in environmental conditions, suchmay be present when car doors open and close These scenarios provideexamples of when the driver device 20 may operate to automaticallydetermine the trip had ended, without any affirmative input from thedriver or rider. In such cases, the trip termination determinator 130can utilize trip data 105 (e.g., position data, velocity and implementlogic to validate or correct automated determinations of tripterminations using sensor data that identifies when the rider has leftthe vehicle.

While an example of FIG. 2A provides for use of passive data inconjunction with driver transport termination input, in variations, thedriver or rider computing device can automate detection of when a giventrip ends. As described, an example of FIG. 2B may be implemented todetermine the point of trip determination with accuracy and withoutinput from the driver.

The service 100 collects passive information from computing devices thatare within the vehicle during the trip (240). In one implementation,this includes a computing device of the driver which communicates tripdata 105 (242). As an addition or variation, the computing device can bethat of the rider (244). In a variation shown by FIG. 2B, the passiveinformation may include GPS data and/or motion information (e.g.,accelerometer readings), as well as sensor readings from the cabin ofthe vehicle (246). For example, the passive information may includeaudio input, corresponding to sounds recorded by a microphone of thedriver device 20 of the vehicle's cabin. As an addition or variation,the passive information may include sensor data for the cabin of thevehicle (e.g., barometric information, temperature).

In an example of FIG. 2B, the service 100 detects, from the passiveinformation, a departure event that is indicative of the rider leavingthe vehicle (250). The detection may be of an event that is caused by avehicle door, or more specifically, a backseat door and/orpassenger-side door, being opened. In one implementation, thedetermination is based on a microphone within the vehicle detecting anaudio signal that is a match to an indicator of the user leaving thevehicle (252). For example, the audio signal may match to the sound ofthe vehicle's door opening and closing, and/or the rider and driversaying goodbye to one another. The microphone within the vehicle may beprovided by the driver device 20. In variations, the microphone may beprovided by the rider device 30, or through another computing device ordevice (e.g., vehicle computer).

In a variation, the determination is based on the environmental sensorof the driver device 20 detecting a change in an environmental conditionor characteristic of the vehicle which is indicative of the vehicle dooropening and closing (254). For example, the driver device 20 may includea barometric sensor that detects when the barometric pressure of thecabin drops. In a variation, the driver device 20 may include athermometer that detects a temperature change in the cabin, which inturn can be correlated to exposure by the cabin of outside air.Depending on the implementation, the environmental sensor may beprovided with the driver device 20, the rider device 30, and/or othersensor device (or computing device) that is integrated or carried withinthe vehicle.

In some variations, the service 100 collects passive information todetermine one or more stopping points of the vehicle during the trip(256). In one implementation, the position information is collected forthe vehicle over the course of the trip, and then used to approximatethe velocity of the vehicle and/or instances when the vehicle may havestopped.

The point of trip determination can be determined based on the passiveinformation (260). In some implementations, the service 100 candetermine the point of trip determination without receiving or otherwiseusing input from the driver (e.g., without receiving trip terminationinput 133). In one implementation, the passive information includessensor data that detects a door of the vehicle opening and closing. Forexample, a microphone of the rider device 20 can detect the sound of thevehicle door opening and closing. Alternatively, an environmental sensorof the driver device 30 can detect a change in the environmentalconditions of the cabin, coinciding with the vehicle door opening andclosing (e.g., change in barometric reading or cabin temperature). Invariations, the microphone of the driver device 20 may detect othersounds which are indicators of trip termination, either to mark thepoint of trip termination or confirm the point of trip termination incombination with other data.

In some variations, determination of the trip termination point is basedon multiple types of passive information and/or determinations (262). Inone implementation, the collected passive information includes positioninformation (e.g., from a GPS component of the rider device 20 and/orvehicle) and/or motion data (e.g., from accelerometer included withvehicle, telemetry data from on-board computing device of vehicle,etc.). The position information and/or motion data may be used to detectwhen the vehicle may have stopped. For example, the point of triptermination may be deemed to be the location where the departure eventis detected, provided that a separately determined vehicle stoppingpoint (such as determined through analysis of GPS data) verifies thelocation of the departure event (e.g., stopping point and location ofdeparture point or approximately same position or within threshold). Asan addition or variation, the point of trip termination may be deemed tobe the stopping point if the stopping point and the location of thedeparture event are deemed to be different (e.g., stopping point andlocation of departure point are different by more than a predeterminedthreshold).

In some variations, a model is implemented to determine the point oftrip termination (264). The model can incorporate information ofdifferent types in order to approximate with accuracy the point of triptermination. In some examples, the model can be based on (i) passiveinformation that identifies a departure event, (ii) passive informationthat identifies a stopping location of the vehicle, and/or (iii) riderdestination input 107. The model may be trained using data collectedfrom monitoring vehicles of a given geographic region, and/or specificdrivers.

As described, an example of FIG. 2B extends to a scenario in which thedriver provides no trip termination input 133. For example, the drivermay begin to look for a stopping space for the vehicle when he arrivesat the approximate location of the drop-off location. Once stopped, therider disembarks, at which time passive information from the driverdevice 20, or the combination of the driver device 20 and rider device30 detect the rider has left the vehicle. Thus, the point of triptermination, coinciding with the actual stopping point where the riderleaves the vehicle (the point of trip termination), may be before orafter an address provided by the rider as the destination input. In anexample of FIG. 2B, the driver does not provide affirmative input aboutthe point of trip termination. Rather, the service 100 automaticallydeduces the point of trip termination from one or more types of passiveinformation.

With respect to examples such as described with FIG. 2A and FIG. 2B, theservice 100 may collect passive information from the vehicle, andperform operations of methods such as described using resources of theservice. Thus, the point of trip termination is determined remotely, ina manner that precludes (or hinders) the ability of driver or rider toinfluence the determination. This allows for a more accurate andreliable mechanism for determining points of trip termination.

While some examples provide for service 100 to perform methods andoperations such as described with FIG. 2A and FIG. 2B, in variations,the driver and/or rider computing device 20, 30 can perform some or alloperations for determining the point of trip termination. For example,the service application 190 of the driver device 20 may be used toperform one or more operations described with FIG. 2A and FIG. 2B, usingbackground processes and/or programmatic functionality that isinaccessible to the driver (so that the driver cannot influence thedeterminations).

With reference to FIG. 3, the service 100 receives the trip terminationinput 133 from the driver (310). A determination is made as to whetherthe driver's vehicle is stationary when trip termination input 133 isreceived (315). If the driver's vehicle is determined to be stationarywhen the trip termination input 133 is received, then the service 100determines that trip termination has occurred (318), and the locationcorresponding to the trip termination input 133 is deemed to be thepoint of trip termination.

If, however, the vehicle is not stopped or stationary when the triptermination input 133 is received, then a determination is made as towhether the vehicle has stopped in a given threshold of time or distance(e.g., within the last minute, or within a 500 feet) (325). If thedetermination is that the vehicle has been stationary within the giventhreshold, then the point of trip termination is set to be the locationwhere the trip data 105 indicates the vehicle stopped (328).

If the determination of (325) is that the vehicle has not stopped withinthe given threshold, then a determination is made as to whether theparticular trip has a known destination (e.g., such as provided by therider destination input 107) (335). If no known destination exists forthe trip, then the point of trip termination is the location closest tothe location of the trip termination input 133 where the vehicle stopped(338).

If the determination of (335) is that the trip has a known destination,then a determination is made as to whether location of the triptermination input 131 is within a designated threshold from the knownlocation (345). If the vehicle is within the threshold, then the pointof trip termination is set to be the known destination (e.g.,destination identified by rider destination input 107) (348). Else, theservice 100 may reject the driver's trip termination input 131, and thedriver may be required to resubmit the trip termination input (352).

Hardware Diagrams

FIG. 4 is a block diagram that illustrates a mobile computing deviceupon which embodiments described herein may be implemented. In oneexample, a computing device 400 may correspond to a mobile computingdevice, such as a cellular device that is capable of telephony,messaging, and data services. The computing device 400 can correspondto, for example, driver device 20 or rider device 30. By way of example,the computing device 400 may correspond to a smartphone, handsets,wearable computing devices, or tablet devices which are wirelesslyenabled (e.g., capable of cellular transmissions). The computing device400 includes a processor 410, memory resources 420, a display device 430(e.g., such as a touch-sensitive display device), one or morecommunication sub-systems 440 (including wireless communicationsub-systems), input mechanisms 450 (e.g., an input mechanism can includeor be part of the touch-sensitive display device), and one or moresensors 460, including a location detection mechanism (e.g., GPSreceiver). In one example, at least one of the communication sub-systems440 sends and receives cellular data over data channels and voicechannels. The communications sub-systems 440 can include a cellulartransceiver and one or more short-range wireless transceivers.

The processor 410 can provide a variety of content to the display 430 byexecuting instructions stored in the memory resources 420. The memoryresources 420 can store instructions corresponding to a driver serviceapplication 425. As described with FIG. 1 (e.g., service application190), the driver service application 425 can enable the driver toprovide transport services, and to provide input corresponding to triptermination input 131 (see FIG. 1). For example, the processor 410 canexecute the service application 425 to perform one or more processes,steps, and other functions described with implementations, such asdescribed by FIGS. 1 through 3, and elsewhere in the application. Amongthe processes performed, the processor 410 may execute the serviceapplication 425 to signal trip data 105 (see FIG. 1) to the service 100.In example of FIG. 4, the trip data 105 can include location data 464(e.g., as determined from the GPS component of the mobile computingdevice 400) and other sensor data 465 (e.g., motion data as determinedfrom the accelerometer of the mobile computing device).

FIG. 5 is a block diagram that illustrates a computer system upon whichexamples described herein may be implemented. For example, in thecontext of FIG. 1, the 100 may be implemented using a computer system(or combination of computer systems) such as described by FIG. 5.

In one implementation, the computer system 500 includes processingresources, such as one or more processors 510, a main memory 520, aread-only memory (ROM) 530, a storage device 540, and a communicationinterface 550. The computer system 500 includes at least one processor510 for processing information and the main memory 520, such as a randomaccess memory (RAM) or other dynamic storage device, for storinginformation and instructions to be executed by the processor 510. Themain memory 520 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by the processor 510. The computer system 500 may also includethe ROM 530 or other static storage device for storing staticinformation and instructions for the processor 510. The storage device540, such as a magnetic disk or optical disk, is provided for storinginformation and instructions. For example, the storage device 540 cancorrespond to a computer-readable medium that stores trip datatermination instructions 545 for determining a point of triptermination, as described by examples of FIG. 1 through 3. In suchexamples, the computer system 500 can determine point of triptermination from driver input (e.g., trip termination input 131 from thedriver) and passively collected data from the driver's device (e.g.,trip data 105).

The communication interface 550 can enable the computer system 500 tocommunicate with one or more networks 580 (e.g., cellular network)through use of the network link (wirelessly or using a wire). Using thenetwork link, the computer system 500 can communicate with a pluralityof devices, such as the mobile computing devices of the riders anddrivers (e.g., driver devices 20, rider devices 30). According to someexamples, the computer system 500 can receive trip data 505 from thedriver devices and use the trip data to determine the point of triptermination, such as described by some examples of FIGS. 1 through 3.

The computer system 500 can also include a display device 560, such as acathode ray tube (CRT), an LCD monitor, or a television set, forexample, for displaying graphics and information to a user. An inputmechanism 570, such as a keyboard that includes alphanumeric keys andother keys, can be coupled to the computer system 500 for communicatinginformation and command selections to the processor 510. Othernon-limiting, illustrative examples of the input mechanisms 570 includea mouse, a trackball, touch-sensitive screen, or cursor direction keysfor communicating direction information and command selections to theprocessor 610 and for controlling cursor movement on the display 560.

Examples described herein are related to the use of the computer system500 for implementing the techniques described herein. According to oneexample, those techniques are performed by the computer system 500 inresponse to the processor 510 executing one or more sequences of one ormore instructions contained in the main memory 520. Such instructionsmay be read into the main memory 520 from another machine-readablemedium, such as the storage device 540. Execution of the sequences ofinstructions contained in the main memory 520 causes the processor 510to perform the process steps described herein. In alternativeimplementations, hard-wired circuitry may be used in place of or incombination with software instructions to implement examples describedherein. Thus, the examples described are not limited to any specificcombination of hardware circuitry and software.

It is contemplated for examples described herein to extend to individualelements and concepts described herein, independently of other concepts,ideas or system, as well as for examples to include combinations ofelements recited anywhere in this application. Although examples aredescribed in detail herein with reference to the accompanying drawings,it is to be understood that the concepts are not limited to thoseprecise examples. Accordingly, it is intended that the scope of theconcepts be defined by the following claims and their equivalents.Furthermore, it is contemplated that a particular feature describedeither individually or as part of an example can be combined with otherindividually described features, or parts of other examples, even if theother features and examples make no mentioned of the particular feature.Thus, the absence of describing combinations should not preclude havingrights to such combinations.

What is claimed is:
 1. A computer system comprising: a networkcommunication interface; a memory storing a set of instructions; aprocessor executing the set of instructions, causing the processor to:based on location data received, over one or more networks, from acomputing device of a driver, remotely monitor positions of a vehicle ofthe driver at different instances in time during a trip in which thedriver transports a rider; receive, over the one or more networks, inputdata indicating a trip termination input from the computing device ofthe driver, the trip termination input signaling termination of the tripby the driver at a termination location; based at least in part onmonitoring the positions of the vehicle and in response to the triptermination input signaling termination of the trip, determine whetherthe termination location corresponding to the trip termination input isvalid, wherein the termination location is valid when the triptermination input correlates to the vehicle being stopped; and inresponse to determining that the termination location is not valid,validate an actual point of trip termination based at least in part onthe positions of the vehicle to determine a fare for the trip.
 2. Thecomputer system of claim 1, wherein the executed instructions furthercause the processor to: receive, over the one or more network,acceleration data from one or more motion sensing components of thecomputing device of the driver; and wherein the executed instructionscause the processor to further determine the actual point of triptermination based on the acceleration data.
 3. The computer system ofclaim 1, wherein the executed instructions cause the processor todetermine that the termination location is not valid by determining,based on the location data from the computing device of the driver, aposition of the vehicle when the driver provides the trip terminationinput.
 4. The computer system of claim 1, wherein the executedinstructions cause the processor to validate the actual point of triptermination by correcting the termination location.
 5. The computersystem of claim 4, wherein the executed instructions cause the processorto correct the termination location by extending the trip to the actualpoint of trip termination.
 6. The computer system of claim 4, whereinthe executed instructions cause the processor to correct the terminationlocation by shortening the trip to the actual point of trip termination.7. The computer system of claim 1, wherein the executed instructionsfurther cause the processor to: receive, over the one or more networks,location data from a computing device of the rider; wherein the executedinstructions cause the processor to further determine the actual pointof trip termination based on the location data from the computing deviceof the rider.
 8. A non-transitory computer readable medium storinginstructions that, when executed by a processor of a computer system,cause the processor to: based on location data received, over one ormore networks, from a computing device of a driver, remotely monitorpositions of a vehicle of the driver at different instances in timeduring a trip in which the driver transports a rider; receive, over theone or more networks, input data indicating a trip termination inputfrom the computing device of the driver, the trip termination inputsignaling termination of the trip by the driver at a terminationlocation; based at least in part on monitoring the positions of thevehicle and in response to the trip termination input signalingtermination of the trip, determine whether the termination locationcorresponding to the trip termination input is valid, wherein thetermination location is valid when the trip termination input correlatesto the vehicle being stopped; and in response to determining that thetermination location is not valid, validate an actual point of triptermination based at least in part on the positions of the vehicle todetermine a fare for the trip.
 9. The non-transitory computer readablemedium of claim 8, wherein the executed instructions further cause theprocessor to: receive, over the one or more network, acceleration datafrom one or more motion sensing components of the computing device ofthe driver; and wherein the executed instructions cause the processor tofurther determine the actual point of trip termination based on theacceleration data.
 10. The non-transitory computer readable medium ofclaim 8, wherein the executed instructions cause the processor todetermine that the termination location is not valid by determining,based on the location data from the computing device of the driver, aposition of the vehicle when the driver provides the trip terminationinput.
 11. The non-transitory computer readable medium of claim 8,wherein the executed instructions cause the processor to validate theactual point of trip termination by correcting the termination location.12. The non-transitory computer readable medium of claim 11, wherein theexecuted instructions cause the processor to correct the terminationlocation by extending the trip to the actual point of trip termination.13. The non-transitory computer readable medium of claim 11, wherein theexecuted instructions cause the processor to correct the terminationlocation by shortening the trip to the actual point of trip termination.14. The non-transitory computer readable medium of claim 1, wherein theexecuted instructions further cause the processor to: receive, over theone or more networks, location data from a computing device of therider; wherein the executed instructions cause the processor to furtherdetermine the actual point of trip termination based on the locationdata from the computing device of the rider.
 15. A method of validatingtrip termination locations, the method being implemented by one or moreprocessors and comprising: based on location data received, over one ormore networks, from a computing device of a driver, remotely monitoringpositions of a vehicle of the driver at different instances in timeduring a trip in which the driver transports a rider; receiving, overthe one or more networks, input data indicating a trip termination inputfrom the computing device of the driver, the trip termination inputsignaling termination of the trip by the driver at a terminationlocation; based at least in part on monitoring the positions of thevehicle and in response to the trip termination input signalingtermination of the trip, determining whether the termination locationcorresponding to the trip termination input is valid, wherein thetermination location is valid when the trip termination input correlatesto the vehicle being stopped; and in response to determining that thetermination location is not valid, validating an actual point of triptermination based at least in part on the positions of the vehicle todetermine a fare for the trip.
 16. The method of claim 15, furthercomprising: receiving, over the one or more network, acceleration datafrom one or more motion sensing components of the computing device ofthe driver; and wherein the one or more processors further determine theactual point of trip termination based on the acceleration data.
 17. Themethod of claim 15, wherein the one or more processors determine thatthe termination location is not valid by determining, based on thelocation data from the computing device of the driver, a position of thevehicle when the driver provides the trip termination input.
 18. Themethod of claim 17, wherein the one or more processors validate theactual point of trip termination by correcting the termination location.19. The method of claim 18, wherein the one or more processors correctthe termination location by extending the trip to the actual point oftrip termination.
 20. The method of claim of claim 18, wherein the oneor more processors correct the termination location by shortening thetrip to the actual point of trip termination.